Embodiments of the present invention relate to a user interface provided by a device driver and to data structures and methods of maintaining consistency of settings accessible via such a user interface.
Computer systems output data to a variety of output devices, such as, printers, plotters, and video displays. These systems also accept input data from a variety of input devices, such as, scanners, network devices, and speech recognition interfaces. Each device typically has a manufacturer-defined device-specific protocol for communicating with the device. A computer system, under the control of an operating system, uses the protocol to communicate with each device. An operating system must, therefore, be programmed to cooperate with the protocol of each device to which it is connected. It would be impractical for an operating system developer to provide an interface to every available peripheral device. Moreover, frequent revisions to an operating system to permit it to cooperate with new peripheral devices may add unnecessary cost to the provision and support of an operating system on multiple computers. To overcome these difficulties, operating systems interface with peripheral devices indirectly through device drivers. The operating system developer defines a device driver interface between the operating system and the device driver. Each manufacturer of a device then provides a device driver, which implements the device driver interface and further, implements the protocol for communicating with the peripheral device. The operating system or application program loads the device driver and invokes the functions of the device driver interface to communicate with the device.
An operating system also provides support for application programs. To this end, the operating system developer defines an application program interface over which an application program may communicate to obtain the services of peripheral devices. Such an application program interface is commonly called a Graphics Device Interface (GDI) and is typically part of the operating system. The GDI effects the output of data by invoking functions implemented by the device driver in accordance with the device driver interface. The GDI and device drivers insulate the application program from the different characteristics of peripheral devices. The GDI provides a variety of functions for accessing devices in a device-independent manner. An example of a GDI is described in Programming Windows 3.1 by Charles Petzold, published by Microsoft Press, incorporated herein by reference. The GDI also specifies behavior of each function that a device driver must implement. For example, one GDI for a printer specifies six categories of functions implemented by a device driver: (1) initialization, (2) information, (3) output, (4) attribute, (5) mode, and (6) escape as described in Table 1.
As an example of the operation of the GDI described above, an application program outputs data to a particular device by first requesting the GDI to create a device context. The device context identifies the particular peripheral device and contains the current state of the peripheral device. For example, the device context may contain the current font and brush information. The GDI provides the application program with a handle to the created device context. The application program passes the handle to the device context whenever the application program outputs data to the particular device. The GDI functions use the passed handle to access the device context.
Each of the functions provided by a device driver may be uniquely programmed by the manufacturer of the peripheral device. This approach leads to several areas of difficulty which add to the cost of providing peripheral devices for mass marketing distribution. For example, when a manufacturer provides several lines of peripheral devices, it is desirable to provide device drivers implemented from reusable software components. In this approach, each new peripheral can be supported with a device driver having consistent behaviors shared with device drivers built for prior peripheral device products. In addition, it is desirable to design device drivers that are portable (i.e., common code reused for different operating systems), flexible (i.e., new features may be added with minimal redevelopment and testing), and consistent (i.e., the structural organization of the device driver software is similar among device drivers for different products and/or different product lines).
A device driver may provide a user interface for permitting the user of an application program to modify selected attributes of the device context. The operating system cooperates with the device driver to provide the user interface. In a conventional user interface, dialog boxes are shown on the screen with controls that respond to user input for the specification of new values for attributes. Because the dialog box provides the user with the flexibility of modifying attributes in an ad hoc manner, conventional device drivers assure that user input will not result in an inconsistent group of attributes.
An attribute is referred to herein as a device setting. A plurality of attributes may be collectively referred to as a device setting or as a plurality of device settings. Therefore, a device setting may include one or more attributes. Each attribute may be referred to as a parameter. Each attribute has an identity and one or more values.
Typically, consistency checks are made prior to modifying the value of a device setting. That portion of the device driver program responsible for accepting a modified device setting for one of the controls of the dialog necessarily is programmed with knowledge of the behavior of one or more other controls. This interaction between controls complicates software development of the device driver user interface. Further, by accounting for consistency checking in the programming of each control, the resulting device driver user interface is less amenable to reuse for the development of future device drivers. Development of device drivers using this approach, therefore, cannot obtain the desirable features discussed above.
In view of the problems described above and related problems that consequently become apparent in the art of device driver development, the need remains for methods of responding to user input provided to a device driver and methods for maintaining the consistency of device settings.
A memory device in one embodiment of the present invention has indicia of a method for responding to user input provided to a device driver. The device driver has settings. Each setting has a respective value. The method includes the steps of (a) in response to user input, establishing, for a first setting having a first value, a second value for the first setting, the second value replacing the first value, the second value being a member of the plurality of values; and (b) after the step of establishing, reviewing for consistency the plurality of values.
By establishing a possibly inconsistent plurality of values and then reviewing for consistency, various consistency checks may be made more efficiently and the programming source code for implementing the method may be written and maintained in a manner less prone to redundant logic.
A memory device in another embodiment of the present invention has indicia of a method for responding to user input provided to a device driver. The device driver has settings. Each setting has a respective value. The method includes the steps of: (a) in response to user input, establishing, for a first setting having a first value, a second value for the first setting, the second value replacing the first value, the second value being a member of the plurality of values; and (b) performing a review after the step of establishing. The review includes the steps of (b1) storing in a first list an indicia of the first setting; and (b2) executing in turn each procedure of a plurality of procedures, each procedure possibly affecting a second list; and (b3) in response to determining that the second list is not empty, performing the following steps: (i) replacing the contents of the first list with the contents of the second list; and (ii) repeating the review. Each procedure of the plurality of procedures includes indicia of a setting to be tested. Each procedure performs the following steps: (a) proceeding with performance of the respective procedure upon successful comparison of the contents of the first list and the respective indicia of a setting to be tested; (b) establishing, for a respective second setting having a third value, a fourth value for the second setting, the fourth value replacing the third value, the fourth value being a member of the plurality of values; and (c) storing in a second list an indicia of the respective second setting.
By using two lists, all procedures review the same context for inconsistency checking, namely the context provided by the first list. Making reference to the first list for context minimizes any consequence of interaction between procedures, simplifying device driver user interface development.
A memory device in a third embodiment of the present invention includes indicia of a method for maintaining consistency of a plurality of settings for a peripheral device. The method includes the steps of (a) modifying at least one setting of the plurality of settings in response to user input; (b) after the step of modifying, validating the plurality of settings by performing a plurality of checks, where each check includes conditionally further modifying the plurality of settings in response to determining that an inconsistency is present among the plurality of settings; and (c) repeating the step of validating, in response to determining that any check determined that an inconsistency indeed was present.